經過前三個專案的洗禮，我對 AI-DLC Sprint 的理解越來越深。MoodStamp、智能記帳、Chrome Extension——每個專案都讓我體會到 AI 協作的威力。但每次都是我自己跟 AI 一對一地幹，就像獨奏樂手。

現在，我想變成指揮家。

今天開始，我要建造一個能讓小團隊快速產生 MVP 的平台。不是我一個人用，而是我們三人團隊一起用。更狂的是，我想把這個平台做成一個 SaaS 服務，讓任何團隊都能使用這套流程。

為什麼要做這個專案？

痛點一：現有工具都太「手動」

用了三個專案後，我發現一個問題：

每次都要重複做同樣的事：

• 寫 PRD（手動跟 AI 對話）
• 拆 User Story（手動跟 AI 對話）
• 設計 UI/UX（手動跟 AI 對話）
• 建 GitHub Repo（手動操作）
• 設定專案結構（手動創建）

而且每次創建 Repo 後，這些 PRD、User Story、設計文件就散落在各處：

• PRD 在 Notion
• User Story 在 Google Doc
• UI 設計在 Figma
• 程式碼在 GitHub

這些資料沒有集中管理，也沒有版本控制。更重要的是，下一個專案就要從頭再來一次。

痛點二：團隊協作的混亂

當我跟兩位夥伴一起開發時，問題更明顯：

每個人用不同的 AI 工具：

• A 用 Claude Code
• B 用 Cursor
• C 用 Windsurf

每個人都在自己的 context 裡工作：

• A 不知道 B 寫了什麼
• B 不知道 C 改了什麼
• C 不知道 A 的設計選擇

沒有統一的知識庫：

• 每個人都要自己給 AI 上下文
• 沒有共享的 Prompt 模板
• 沒有統一的開發規範

結果就是：溝通成本高、效率低下、品質不一致。

痛點三：每個專案都是孤島

做完三個專案後，我累積了一堆經驗：

• 什麼樣的 PRD 結構最有效
• 什麼樣的 User Story 拆法最好
• 什麼樣的 Prompt 最精準
• 什麼樣的流程最順暢

但這些經驗全部在我腦袋裡，沒有系統化、沒有標準化、沒有可複用。

下一個專案還是要從頭摺索。

我想做什麼？

核心想法：一個 AI-DLC Sprint 的自動化平台

我想建立一個 Web 平台，讓使用者可以：

階段一：Spec Input（規格輸入）

1. 輸入需求 - 用自然語言描述想做什麼
2. AI 提問 - 平台自動生成澄清問題
3. 對話釐清 - 使用者回答，AI 繼續問
4. 生成 PRD - 最終產出結構化的 PRD

階段二：Sprint Execution（Sprint 執行）

1. 拆解 User Story - 自動從 PRD 生成 Stories
2. 使用者介入 - 可以手動調整、增刪 Story
3. 生成 Task List - 每個 Story 拆成具體任務
4. 分配 AI 同事 - 讓不同 AI Agent 負責不同環節

階段三：GitHub Integration（GitHub 整合）

1. 建立組織 Repo - 自動在 GitHub Org 建 Repo
2. 同步文件 - PRD、Stories 自動 commit 到 Repo
3. 建立 Issue - 每個 Task 自動轉成 GitHub Issue
4. 開發協作 - 團隊成員在 GitHub 上協作開發

階段四：Development & Deployment（開發與部署）

1. 連接 Claude Code - 用 API 讓 Claude Code 存取平台資料
2. AI 開發 - AI 根據 Task 生成程式碼
3. 人工審核 - 開發者可介入修改
4. 一鍵部署 - 自動部署到雲端（Vercel/Railway）

關鍵特色：為什麼這個平台不一樣？

1. Spec-Driven Development 的實踐

還記得 GitHub 的 Spec-Driven Development 嗎？我要把這個理念徹底實踐：

傳統方式：
想法 → 直接寫 code → 發現不對 → 改 code → 又不對 → ...

Spec-Driven 方式：
想法 → 寫 Spec → AI 生成 PRD → AI 拆 Stories → AI 生成 code → 一次就對

2. 團隊共享的 AI Context

每個團隊成員都能存取同一份：

• PRD 文件
• User Stories
• 設計決策
• 開發規範
• Prompt 模板

不用再每個人都自己給 AI 上下文了！

3. 可擴展的 AI Agent 系統

平台內建了多個 AI Agent：

• Product Manager Agent - 負責 PRD 生成
• Business Analyst Agent - 負責 User Story 拆解
• UX Designer Agent - 負責 UI/UX 設計
• QA Engineer Agent - 負責測試策略
• Developer Agent - 負責程式開發

使用者可以：

• 選擇要用哪些 Agent
• 自己新增客製化 Agent
• 調整每個 Agent 的 Prompt

4. GitHub 原生整合

不是另外做一個專案管理系統，而是直接跟 GitHub 整合：

• 所有文件都在 GitHub
• 所有 Task 都是 GitHub Issue
• 所有 code 都在 GitHub Repo
• 所有版本都由 Git 管理

不用在多個平台之間跳來跳去！

5. 每個專案都能累積知識

平台會記錄：

• 哪些 Spec 結構最有效
• 哪些 User Story 拆法最好
• 哪些 Prompt 最精準
• 哪些流程最順暢

下一個專案就能立刻使用這些最佳實踐！

技術方案選擇

根據前三個專案的經驗，我決定用 TDD 來開發這個平台。

為什麼選 TDD？

理由一：AI Workflow 在 TDD 流程上比較順

經過三個專案的實踐，我發現：

TDD 的 Red-Green-Refactor 循環跟 AI 的工作方式天生契合：
Red Phase（寫失敗的測試）
↓
AI 幫你生成測試案例，包含邊界條件、異常情況
↓
Green Phase（寫最少實作）
↓
AI 生成初版 code，你審核調整
↓
Refactor Phase（重構優化）
↓
AI 建議重構方案，測試保護安全網

理由二：測試就是 Spec

TDD 的測試案例其實就是 可執行的規格：
// 這不只是測試，更是規格定義

describe('PRD Generator', () => {
it('should generate structured PRD from user input', async () => {
// Given: 使用者輸入簡單描述
const userInput = '我想做一個任務管理 App';

// When: AI 生成 PRD
const prd = await prdGenerator.generate(userInput);

// Then: PRD 必須包含核心欄位
expect(prd).toHaveProperty('title');
expect(prd).toHaveProperty('objectives');
expect(prd).toHaveProperty('userStories');
expect(prd).toHaveProperty('technicalRequirements');

});
});

這個測試就明確定義了：

• PRD Generator 要接受什麼輸入
• 要產出什麼輸出
• 輸出的結構是什麼

理由三：對於複雜系統更安全

這個平台會很複雜：

• 多個 AI Agent 互相協作
• GitHub API 整合
• 實時協作功能
• 權限控制系統

有完整的測試，我才敢大膽重構和增加功能。

技術棧選擇

基於 TDD 和三個專案的經驗，我選擇：

前端

• Next.js 14 (App Router)
• TypeScript (型別安全)
• Tailwind CSS (快速開發)
• shadcn/ui (組件庫)

後端

• Next.js API Routes (簡化架構)
• Supabase (資料庫 + Auth)
• Anthropic Claude API (AI 引擎)

整合

• Octokit (GitHub API 客戶端)
• Vercel (部署平台)

測試

• Vitest (單元測試)
• Playwright (E2E 測試)
• MSW (API Mock)

專案命名：跟 AI 一起決定

這次我不想自己想名字了，讓 AI 幫我想幾個選項。

我的 Prompt

我要建立一個 AI-DLC Sprint 自動化平台，主要功能：

1. Spec-Driven: 讓使用者輸入需求，自動生成 PRD
2. Sprint Automation: 自動拆解 User Story、建立 Task
3. GitHub Integration: 自動創建 Repo、Issue、同步文件
4. Team Collaboration: 支援小團隊協作、AI Agent 系統
5. Knowledge Accumulation: 每個專案的經驗都能累積

請幫我想 5 個合適的 GitHub Repo 名稱，要求：

• 簡短有力（最好 1-2 個單字）
• 能夠表達核心價值
• 易讀易記
• 具有現代感
• 可以當作品牌名稱

每個名稱請附上：

1. 名稱的意義
2. 為什麼選這個名字
3. 可能的 slogan

AI 的建議

AI 給了我五個選項：

1. SprintForge

意義：Forge 意指「鍛造場」，象徵把想法鍛造成產品

選擇理由：

• Sprint + Forge 結合，表達「快速鍛造」的核心價值
• Forge 有工匠精神，符合品質導向
• 音節有力，好記易唱

Slogan："From Idea to Product, in One Sprint"

2. BoltHQ

意義：Bolt 是 AI-DLC 的核心概念（超短迭代），HQ 代表總部/中心

選擇理由：

• Bolt 直接引用 AI-DLC 術語，讀者有連結感
• HQ 讓人聯想到指揮中心，強調協作
• 簡短有力，現代感十足

Slogan："Ship MVPs at Lightning Speed"

3. SpecFlow

意義：Spec + Flow，讓規格流動起來

選擇理由：

• 強調 Spec-Driven Development 的核心
• Flow 表達流程的順暢、自然
• 音韻優雅，易於傳播

Slogan："Turn Specs into Shippable Products"

4. LaunchPad

意義：發射台，讓專案快速起飛

選擇理由：

• 象徵從 0 到 1 的加速過程
• 簡單直觀，一聽就懂
• 有動能感，符合快速 MVP 的定位

Slogan："Your Ideas, Ready for Liftoff"

5. Momentum

意義：動量、動力，持續的進展動能

選擇理由：

• 象徵持續迭代、加速開發
• 單一單字，有力量感
• 可以延伸到「Keep Your Momentum」這樣的 slogan

Slogan："Build, Ship, Repeat. Keep Your Momentum."

我的決定：BoltHQ

思考了一陣子，我決定選 BoltHQ。

為什麼？

1. 跟 AI-DLC 術語直接連結
   • Bolt 是 AI-DLC 的核心概念
   • 讀者看到就知道這是什麼
2. HQ 的意義很好
   • 不只是工具，而是團隊的指揮中心
   • 有協作的感覺
3. 簡短有力且現代
   • 僅 6 個字母
   • 好讀好記
   • 可以當品牌名稱
4. Slogan 很精準
   • "Ship MVPs at Lightning Speed"
   • 完美表達了核心價值

專案資訊

Project Name: BoltHQ
Tagline: Ship MVPs at Lightning Speed
Description: AI-Powered Sprint Automation Platform for Fast-Moving Teams

Core Features:

• Spec-Driven PRD Generation
• Automated User Story Decomposition
• GitHub Native Integration
• Multi-Agent AI System
• Team Collaboration Hub
• Knowledge Accumulation Engine

Tech Stack:
Frontend: Next.js 14 + TypeScript + Tailwind
Backend: Next.js API + Supabase
AI: Anthropic Claude API
Integration: Octokit (GitHub API)
Testing: Vitest + Playwright
Deploy: Vercel

Development Approach: Test-Driven Development (TDD)
Team Size: 3 developers
Timeline: 6 days MVP Sprint

接下來的六天計畫

Day 1（今天）：需求釐清 + Repo 建立

✅ 完成

Day 2：PRD 文件 + 技術規劃

• 用 AI 生成完整 PRD
• 確定資料庫 Schema
• 設計 API 結構
• 寫 User Stories

Day 3：User Story & AC

• 拆解每個 Story 的 AC
• 設計測試策略
• 建立 GitHub Issues

Day 4：UI/UX Design + 核心功能 TDD

• 設計主要頁面 Wireframe
• TDD 開發 PRD Generator
• TDD 開發 Story Decomposer

Day 5：GitHub 整合 + AI Agent 系統

• TDD 開發 GitHub API 整合
• 實作 AI Agent 系統
• E2E 測試

Day 6：整合測試 + 部署 + 回顧

• 完整流程測試
• Vercel 部署
• 專案回顧與心得

今天的收穫

✅ 明確了專案目標：建立 AI-DLC Sprint 自動化平台
✅ 識別了核心痛點：手動、散落、孤島、不累積
✅ 定義了關鍵特色：Spec-Driven、共享 Context、AI Agents、GitHub 原生
✅ 決定了開發方法：TDD，因為跟 AI Workflow 最契合
✅ 選定了專案名稱：BoltHQ，簡短有力且有意義
✅ 規劃了六天計畫：每天都有明確目標

結論：從使用者變成創造者

這三個專案讓我學會了如何使用 AI-DLC Sprint，但這個專案要讓我學會如何創造 AI-DLC Sprint 的工具。

從使用者變成創造者，這就是成長。

「最好的工具是自己做的，因為你最懂自己的痛點。」